home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 4 / ETO Development Tools 4.iso / Essentials / MacApp Documentation / MacApp.TECH$ Archives / 1990 / Aug 90 / MacApp.Tech$ 8⁄31⁄90 / 1824-Unresolved MacApp 2.-Aug90 < prev    next >
Encoding:
Text File  |  1991-03-06  |  4.3 KB  |  122 lines  |  [TEXT/GEOL]

  1. Item forwarded  by  PAPERFREE    to PERSOFT
  2.  
  3. Item    1079984                         25-Aug-90        20:17PDT
  4.  
  5. From:   D2022                           Strata, Gary Bringhurst,PRT
  6.  
  7. To:     MACAPP.TECH$                    MacApp Technical
  8.  
  9. Sub:    Unresolved MacApp 2.0 bugs
  10.  
  11. My life is one long series of frustrations.  If you don't believe me, just ask
  12. my wife.  This week I received system 6.0.6b11, installed it for testing, and
  13. found to my joy and surprise that ALL MacApp 2.0 final applications BOMB
  14. HORRIBLY under it.  Then I spent a couple of days updating MacApp with the
  15. published bug fixes.  Happily, this appears to eliminate all bombs under system
  16. 6.0.6b11.  Unhappily we are now in the position of having to update our user
  17. base "one more time."  It appears that the new system has simply smoked out
  18. some nasty bugs that were just lurking in the shadows.
  19.  
  20. For the MacApp boys:  There are several side-effects resulting from the bug
  21. fixes for MacApp 2.0 final.  Once again (yet again?) we have been burned by
  22. "semantic changes" in MacApp when once we thought it stable.  In particular I
  23. must ask, why has TView.IsViewEnabled been changed to be dependent upon
  24. TView.IsShown???  It appears to be a modification that was convenient for
  25. MacApp, but has really screwed the pooch on our side.  Whether or not a view is
  26. shown has no relevance to whether it is enabled.  If you must avoid dinking on
  27. a hidden enabled control, please just check to see that it is both visible and
  28. enabled.  Now many of the preparations we make in our code before posing a
  29. modal dialog window, such as selecting an EditText field, do not work as
  30. expected because the window is not yet shown, therefore the controls are
  31. assumed disabled and the floating edit text is not properly initialized.
  32.  
  33. So, for everyone out there -- your MacApp 2.0 based applications are much more
  34. unstable than you would ever have believed.  Beware!
  35.  
  36. Gary L. Bringhurst
  37. Strata Inc.
  38. D2022
  39.  
  40. P.S.  One of my early links about bugs in MacApp 2.0 has been quoted to provide
  41. the title for technical note #280: "Bugs in MacApp?  Yes, but I love it!"  Can
  42. I take it back now?  I think my enthusiasm for a buggy MacApp has gone along
  43. with my stomach lining.
  44.  
  45. "The paranoia and frustration expressed above is my own, and does not reflect
  46. the paranoia and frustration of Strata or its management."
  47.  
  48.  
  49. --------
  50. The following list consists of additional bugs in the MacApp 2.0 final code
  51. that are not addressed by the bug fix package just released:  (please note that
  52. the windowKind field contains the window "class," such as dialogKind or
  53. userKind, NOT the window variant)
  54.  
  55.  
  56. ***    TApplication.InModalMenuState
  57.  
  58. -- Current fixed version:
  59.    IF (WMgrToWindow(aWindowPtr) = NIL) & (aWindowPtr <> NIL) THEN
  60.    CASE WindowPeek(aWindowPtr)^.windowKind OF
  61.    dBoxProc, plainDBox, altDBoxProc:
  62.    InModalMenuState := TRUE;
  63.    END
  64.    ELSE
  65.  
  66. -- Really fixed version:
  67.    IF (WMgrToWindow(aWindowPtr) = NIL) & (aWindowPtr <> NIL) THEN BEGIN
  68.    IF TrapExists(_GetWVariant) THEN
  69.    windowVariant := GetWVariant(aWindowPtr)
  70.    ELSE
  71.    windowVariant := BAND($0F,
  72. BSR(LONGINT(WindowPeek(aWindowPtr)^.windowDefProc), 24));
  73.    CASE windowVariant OF
  74.    dBoxProc, plainDBox, altDBoxProc:
  75.    InModalMenuState := TRUE;
  76.    END;
  77.    END ELSE
  78.  
  79.  
  80. ***    TApplication.InModalState
  81.  
  82. -- Current fixed version:
  83.    IF (WMgrToWindow(aWindowPtr) = NIL) & (aWindowPtr <> NIL) THEN
  84.    CASE WindowPeek(aWindowPtr)^.windowKind OF
  85.    dBoxProc, plainDBox, altDBoxProc:
  86.    InModalState := TRUE;
  87.    END
  88.    ELSE
  89.  
  90. -- Really fixed version:
  91.    IF (WMgrToWindow(aWindowPtr) = NIL) & (aWindowPtr <> NIL) THEN BEGIN
  92.    IF TrapExists(_GetWVariant) THEN
  93.    windowVariant := GetWVariant(aWindowPtr)
  94.    ELSE
  95.    windowVariant := BAND($0F,
  96. BSR(LONGINT(WindowPeek(aWindowPtr)^.windowDefProc), 24));
  97.    CASE windowVariant OF
  98.    dBoxProc, plainDBox, altDBoxProc:
  99.    InModalState := TRUE;
  100.    END;
  101.    END ELSE
  102.  
  103.  
  104.  
  105. ***    DoInitUMemory
  106.  
  107. -- Current fixed version:
  108.    { Figure the highest segment number }
  109.    IF qNeedsROM128k | gConfiguration.hasROM128k THEN
  110.    lastRsrc := MACount1Resources(kCode) - 1
  111.    ELSE
  112.    lastRsrc := MACountResources(kCode) - 1;
  113.  
  114. -- Really fixed version:
  115.    { Figure the highest segment number.  (Why were we avoiding the last code
  116. segment???)}
  117.    IF qNeedsROM128k | gConfiguration.hasROM128k THEN
  118.    lastRsrc := MACount1Resources(kCode)
  119.    ELSE
  120.    lastRsrc := MACountResources(kCode);
  121.  
  122.